1. Field of the Invention
The present invention relates to an information processing apparatus, a defect analysis program, a defect analysis method and application program development assistance system used for testing and debugging multitask programs operating on a real-time OS (Real-time Operating System).
2. Description of the Related Art
The application range of real-time OS represented by a TRON (The Real-time Operating System Nucleus) goes on increase following the development of microprocessor technique. The real-time OS is applied not only to the industrial field but also to the business equipment field such as communications equipment and office equipment as well as ordinary life equipment such as home appliances and portable telephones.
Normally, it is not easy to trace the movements of programs so as to analyze the discrepancies of a multitask type application program running on such a real-time OS. Since the real-time OS adopts a multitask scheme for executing a plurality of programs by changing over tasks operating at specific timing one after another, the defect of the program cannot be analyzed only by tracing one program.
Under these circumstances, an OS which functions to trace program operations has been developed. According to this OS, program execution history information is employed as one of the keys to analyze program operation states. As shown in FIG. 1, program execution history information 4 is outputted onto a memory of an OS 101 by an OS 101 having a program operation tracing function and further outputted on a memory held by a debugger 102 or the like by a development tool thereof.
FIG. 3 shows an example of program execution history information on a program compliant with μITRON (Micro Industrial TRON). FIG. 3(a) is an example of the format of a system call issuance history, where one record represents one event. This format consists of function type (type), issuance origination task (oid), system call type (sysid) and issuance destination task (obj). Types of execution history information to be outputted involve task change-over history information, handler execution history information and the like in addition to the above-stated system call issuance history information.
FIG. 3(b) shows one example of execution history data outputted onto the memory by the OS 101, the debugger 102 or the like. In FIG. 3(b), symbol (i) indicates that a task is changed over to another task and that control is moved from an idle state (task=0) to a task 1 (task=1). Symbol (ii) indicates that a system call is issued and that a system call of such a type as sta_tsk (sysid=−19) is issued from the task 1 (oid=1) to a task 2 (obj=2).
As stated above, although program execution history has been able to be stored as data and the history is used as a key to analyze the defect of the program, the following problems arise.
First, because of the memory capacity of a controller, there is a limit to the quantity of history information which can be acquired. Actually, as shown in FIG. 2, history information is stored in pieces. In case of a system intended to be provided at low cost, particularly, the memory capacity of the system is greatly limited.
Second, as shown in FIG. 3, history information to be outputted is a series of characters mainly consisting of numbers and tends to be outputted in large quantity. Due to this, it is quite difficult to analyze a program defect by following a program operation trace using the history information.
As a result, it still takes lot of time to analyze the program defect, which has had great effect on development cost and development time.
Third, conventionally, the programming steps performed for an execution environment includes: grasping a state change of a resource under the control of the execution environment; and a judging the coincidence of the programming contents. Even if one can perform programming in consideration of an interrupt function or the like that execution environment hardware has, there is no way to check the coincidence. Thus, there has been a method for actually executing an execution object created from its program under the same conditions as execution environment, thereby checking a behavior of an application system.
However, in the above-described conventional method, even if a simple programming error occurs, such error cannot be judged as long as the execution object is actually executed.